-
Notifications
You must be signed in to change notification settings - Fork 8
Refactor AEM service and ContentMapper to enhance modular block handl… #931
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ing and UID resolution. Updated functions to use resolved content type UIDs, improved schema processing for modular blocks and child blocks, and ensured backward compatibility. Adjusted interfaces and mapping logic for better integration of modular structures.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR refactors the AEM service and ContentMapper to enhance modular block handling and UID resolution. The changes introduce comprehensive support for modular blocks (a structural field type similar to groups but with multiple named block types), improve schema processing for nested structures, and add UID resolution through a keyMapper.
Changes:
- Added modular_blocks and modular_blocks_child field types with proper type mappings and nested schema handling
- Refactored processFieldsRecursive in aem.service.ts to handle modular blocks hierarchically with child block processing
- Enhanced ContentMapper UI to build nested structures for modular blocks and generate appropriate field options
- Updated addUidToEntryMapping to use resolved content type UIDs via keyMapper for flexible UID mapping
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 11 comments.
| File | Description |
|---|---|
| ui/src/components/ContentMapper/index.tsx | Added type definitions for modular_blocks fields, implemented hierarchical schema generation in generateSourceGroupSchema, and enhanced processSchema to handle nested modular block structures with child blocks |
| ui/src/components/ContentMapper/contentMapper.interface.ts | Extended ContentTypesSchema interface to support blocks array and added 'blocks' and 'modular_blocks_child' data types |
| api/src/utils/content-type-creator.utils.ts | Fixed typos in comments, added recursive comment for child blocks, and implemented mergeTwoCts logic for merging modular block schemas |
| api/src/services/aem.service.ts | Refactored addUidToEntryMapping to accept resolved UID instead of ContentType object, restructured modular_blocks processing to iterate through child blocks hierarchically, and added keyMapper parameter to createEntry for UID resolution |
Comments suppressed due to low confidence (1)
api/src/services/aem.service.ts:686
- The comment states 'This is for backwards compatibility', but the backwards compatibility path (modular_blocks_child case) uses different logic than the new modular_blocks case. The old case returns 'data' array while the new case returns 'obj[uid]'. This means code that relied on the old behavior will receive a different data structure. Additionally, the old case uses field.uid for blockTypeUid while the new case uses getLastKey(childBlockSchema?.contentstackFieldUid). This inconsistency could cause issues if both code paths are expected to produce the same output for the same input, which backward compatibility typically implies.
case 'modular_blocks_child': {
// This case is handled in the modular_blocks case above
// This is for backwards compatibility
const list: any[] = (() => {
if (Array.isArray(items)) return items;
const order = Array.isArray(items?.[':itemsOrder']) ? items[':itemsOrder'] : null;
const map = items?.[':items'] || items;
if (order && map) return order.map((k: string) => map?.[k]).filter(Boolean);
return Object.values(map || {});
})();
const uid = getLastKey(field?.contentstackFieldUid);
const blockTypeUid = field?.uid;
for (const value of list) {
if (!value || typeof value !== 'object') continue;
const typeValue = (value as any)[':type'] || '';
const getTypeComp = getLastKey(typeValue, '/');
if (getTypeComp !== blockTypeUid) continue;
const compValue = processFieldsRecursive(
field.schema,
value,
title,
pathToUidMap,
assetDetailsMap
);
if (compValue && Object.keys(compValue).length) {
const objData: any = {};
objData[uid] = compValue;
data.push(objData);
}
}
break;
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…ssing and validation. Enhanced UID resolution logic, added error handling for parent-child relationships in modular blocks, and optimized schema merging for better performance and reliability - Copilot Review
… block handling. Removed unused overrides in package.json and optimized logic for identifying existing fields and blocks during merging, enhancing performance and reducing redundancy.
…ing and UID resolution. Updated functions to use resolved content type UIDs, improved schema processing for modular blocks and child blocks, and ensured backward compatibility. Adjusted interfaces and mapping logic for better integration of modular structures.